AN OPERATIONAL SAFETY AND CERTIFICATION ASSESSMENT OF A 

TASAR EFB APPLICATION 

Stefan Koczo, Rockwell Collins, Cedar Rapids, IA 
David Wing, NASA Langley Research Center, Hampton, VA 


Abstract 

This paper presents an overview of a Traffic 
Aware Strategic Aircrew Requests (TASAR) 
Electronic Flight Bag application intended to inform 
the pilot of trajectory improvement opportunities 
while en route that result in operational benefits. 
The results of safety analyses and a detailed review 
of Federal Aviation Administration (FAA) regulatory 
documents that establish certification and operational 
approval requirements are presented for TASAR. 

The safety analyses indicate that TASAR has a 
likely Failure Effects Classification of “No Effect,” 
and at most, is no worse than “Minor Effect.” Based 
on this safety assessment and the detailed review of 
FAA regulatory documents that determine 
certification and operational approval requirements, 
this study concludes that TASAR can be implemen- 
ted in the flight deck as a Type B software 
application hosted on a Class 2 Portable Electronic 
Device (PED) Electronic Flight Bag (EFB). This 
implementation approach would provide a relatively 
low-cost path to certification and operational 
approval for both retrofit and forward fit 
implementation, while at the same time facilitating 
the business case for early ADS-B IN equipage. A 
preliminary review by FAA certification and 
operational approvers of the analyses presented here 
confirmed that the conclusions are appropriate and 
that TASAR will be considered a Type B application. 

Introduction 

NASA Langley Research Center has developed 
the Traffic Aware Strategic Aircrew Requests 
(TASAR) concept and is conducting and leading 
research efforts toward transition and adoption of this 
capability as an early NextGen flight-deck 
application. Utilizing network-enabled connectivity, 
information from avionics, including Automatic 
Dependent Surveillance Broadcast (ADS-B) IN 
traffic data, TASAR serves as a decision aid to the 
pilot for route improvement opportunities during 


flight to take advantage of changing conditions in the 
airspace environment. [ 1] [2] [3] [4] 

Rockwell Collins is supporting NASA in safety 
analyses and identifying requirements toward 
successful certification and operational approval of 
TASAR, which are examined in detail in this paper. 
The TASAR EFB application is currently being 
developed by NASA to leverage emerging flight deck 
technologies for cost-benefits to current flight 
operations. Among the systems and technologies that 
comprise or support TASAR are flight-optimizing 
software algorithms, a software hosting device such 
as a PED EFB, Automatic Dependent Surveillance 
Broadcast (ADS-B) IN and other sources of traffic 
information, and additional ground-based information 
via data link, internet connectivity, etc. TASAR seeks 
to provide cost-beneficial optimization with respect 
to the current flight plan, taking traffic and other 
constraints into account. Using these information 
sources, the TASAR application has the ability to 
react in an agile manner to changes in the external 
airspace environment (e.g., adverse weather, winds, 
airspace constraints, and/or improved timeliness and 
accuracy of information about factors that affect the 
aircraft’s execution of its flight plan). 

The TASAR EFB application (referred to hence 
as TASAR) is a flight deck-based decision support 
tool that seeks to identify and recommend trajectory 
improvement opportunities to the pilot that have high 
probability of approval by Air Traffic Control (ATC). 
Utilizing available information of own-ship flight 
status, route, and airspace environment (e.g., 
proximate traffic, weather, winds, special activity 
airspace status), TASAR seeks to identify and 
recommend candidate trajectory improvements for 
consideration by the pilot that have higher probability 
of ATC approval. The pilot, at his or her discretion, 
can choose to issue a change request to ATC based 
on TASAR recommended trajectory change 
candidates. 

Prior to recommending trajectory change 
candidates to the pilot, TASAR performs the 
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following: 1) it evaluates the proposed trajectory 
changes against available on-board traffic data for 
potential conflicts, and 2) it may account for known 
ATC sector rules and own-ship’s position relative to 
the sector. Recommended trajectory change request 
candidates from TASAR are expected to have the 
following characteristics: 

1) Meet operational goals for the flight, as provided 
by pilot preferences and route constraints that are 
input to TASAR 

2) Provide improvement to the current flight plan in 
terms of time and / or fuel saved or other desired 
attributes such as passenger comfort. 

3) Have a high potential for approval by ATC by 
considering ATC factors in the identification 
process 

TASAR change request candidates are advisory- 
only to the pilot, and the pilot has full discretion on 
whether or not to use a TASAR-provided trajectory 
change as a change request to ATC. Pilot training 
will emphasize that aviate -navigate-communicate 
priorities and normal procedures for coordination 
with ATC are to be followed as in today’s operations. 
The pilot has responsibility to evaluate TASAR- 
provided trajectory change candidates for operational 
acceptability before making a change request to ATC 
to minimize spurious requests from being made. 
ATC retains authority to approve trajectory changes, 
and ATC will not approve change requests from the 
pilot that do not meet ATC constraints and 
requirements. 

This paper is organized into two major analysis 
sections. The first section presents the TASAR 
Operational Safety Assessment. The second section 
presents an analysis of EFB Standards Adherence. 
The paper concludes with feedback from FAA 
certification and operational approval officials on 
these analyses and a summary of additional activities 
underway to support early implementation of the 
TASAR concept. 

TASAR Operational Safety Assessment 

Two safety assessment methodologies were used 
that are compliant with the Federal Aviation 
Administration’s Safety Management System (SMS) 
for certification and approval of aircraft avionics 
functions such as TASAR: 


1) A traditional safety assessment using 
Aviation Recommended Practice (ARP) 
4761 [5], Advisory Circular (AC) 25-1309 
[6] and AC 23-1309 [7] for Part 25 and Part 
23 aircraft operations (Method 1) 

2) An Operational Safety Analysis (OSA) based 
on RTCA DO-264 / EUROCAE ED-78A [8] 
(Method 2). 

This section provides a high-level description 
and application of the two safety methodologies, 
which provided complementary results and thus 
strengthen the determination of the TASAR Failure 
Effects Classification. In analyzing the safety case, 
the “intended function” of TASAR must be 
considered in order to properly assess the operational 
hazards associated with the application. The TASAR 
intended function is described after the following 
brief overview of the two safety assessment methods. 

Method 1 Safety Assessment 

Method 1 represents the traditional safety 
analysis approach [5] [6] [7] to determine the Failure 
Effects Classification of the aircraft function under 
consideration, in this case, TASAR. This leads to the 
assignment of the Design Assurance Fevel, which 
then determines the hardware and software 
development processes that must be followed and the 
requirements that must be met for certification and 
operational approval of the system. 

Method 1 performs the following steps relative 
to the intended function of the new system capability, 
i.e., TASAR: 

1) Evaluate the intended function per phase of flight 

2) Identify failure events, e.g., loss of function; 
undetected errors 

3) Examine the effect of these failures on aircraft, 
flight crew, and Air Traffic Control (ATC) 

4) Determine the Hazard Classification, e.g.. Major, 
Minor, No Effect 

5) Determine frequency of occurrence, e.g., per 
flight hour, per operation 

6) Provide rationale for hazard assessment. 

Method 2 Safety Assessment 

Method 2 [8] represents an analysis approach 
that is well-suited for allocating safety requirements 
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of avionics functions consisting of multiple systems. 
This allows a more balanced allocation of safety 
requirements across systems and sub-systems, which 
is particularly beneficial for higher criticality 
systems. While an excellent approach for systems - 
of-systems analysis, it is not as well suited for lower 
criticality systems, e.g., “Minor,” which puts 
excessive emphasis on quantitative analysis of 
operational effects such as workload that are often 
highly subjective and difficult to assess. A strength of 
Method 2 is that it provides a more comprehensive 
assessment of operational hazards, which is why this 
analysis method was used to complement Method 1 . 

Method 2 follows these evaluation steps: 

1) Perform an Operational Hazard Assessment 

a) Identify Operational Hazards 

b) Determine the worst credible outcome of the 
Operational Hazard, i.e., the Operational 
Effect, e.g., collision, loss of separation, 
workload 

c) Determine the Severity Classes for each 
Operational Effect, e.g.. Catastrophic, Major, 
Minor, and identify the maximum allowable 
probability of occurrence of the Operational 
Effect 

d) Determine the Effects Probabilities, which 
represent probabilities of available mitiga- 
tion(s) to the system that reduce the probab- 
ility of occurrence of the Operational Effect 
that may result from the Operational Hazard 

e) Assign Safety Objectives, which represent 
the probability of occurrence of each 
Operational Hazard that is allowable for 
ensuring the safety of the application 

f) Identify External Mitigation Means, i.e., 
barriers external to the application that 
reduce the adverse effects and impact to 
safety when Operational Hazards occur. 

2) Allocate Safety Objectives and Safety 

Requirements 

a) Identify Abnormal Events, i.e., failures due 
to human actions, and Basic Causes, i.e., 
failures due to actions by automation that are 
internal to the application that could lead to 
the occurrence of each Operational Hazard 

b) Identify Internal Mitigation Means, i.e., 
barriers internal to the application that reduce 


the probability of the Operational Hazard 
from occurring in order to achieve the 
required Safety Objective 

c) Allocate Safety Requirements to the sub- 
functions comprising the application. 

TASAR Intended Function Description 

The intended function of TASAR, as a flight 
deck decision aid consisting of software automation 
that provides advisory-only service to the pilot, is to 
seek trajectory improvement opportunities over the 
current flight plan and to display these improvements 
as candidate change requests in textual form to the 
flight crew. A simple graphical display of the 
proposed route change may be used for cross- 
checking and verification. TASAR is expected to be 
implemented as a hosted software application on an 
EFB. 

Based on inputs provided by: 1) the pilot in the 
form of flight objectives and optimization criteria, 2) 
on-board avionics systems in the form of current 
aircraft state, flight plan, traffic data, etc., and 3) 
airborne internet data connectivity, the TASAR 
application computes available change request 
candidates that may improve the current flight plan. 
Change request candidates are intended to have 
relatively high probability of ATC approval, as 
TASAR seeks to account for ATC factors such as 
traffic separation and airspace boundaries. 

The pilot has full discretion on the use of 
TASAR-provided change request information; he can 
choose to use TASAR-recommended change request 
candidates as part of a change request to ATC, or he 
can choose to ignore them. TASAR can be manually 
inhibited at any time, for any reason. Thus, in the 
event of observed spurious behavior of TASAR due 
to any system failure, inaccurate data obtained via 
network enabled information sources, or TASAR 
being a source of distraction to the flight crew, the 
pilot can simply inhibit or ignore TASAR. By 
following their training, the pilot can manage the use 
of TASAR in such away so that TASAR will not 
result in any workload increase in the flight deck. 

TASAR is strictly a supplemental system intend- 
ed to provide operational benefits without adversely 
impacting safe operations, and it does not replace any 
aircraft system or procedure needed for flight 
operations. The TASAR display is passive with no 
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graphical display of traffic or audible alerting. Loss 
of the TASAR EFB application for any reason does 
not affect the Minimum Equipment List (MEL) and 
does not affect normal flight operations. 

TASAR information sources may include: 

1) Own-ship systems (aircraft state, auto-flight 
settings, flight plan and performance information 
from Flight Management System (FMS), 
Electronic Flight Instrument Systems (EFIS), 
etc.) 


2) Traffic data via ADS-B IN, Traffic Information 
Service Broadcast (TIS-B), or other sources 

3) Airspace constraints (sector boundaries, special 
activity airspace status, etc.) 

4) Weather status / forecast 

5) Wind status / forecast 

6) Operator flight planning, preferences, objectives 

Figure 1 illustrates the TASAR functional 
diagram identifying the information interfaces. 



Figure 1 TASAR Functional Diagram 


Method 1 Safety Analysis 

The key outcome of this safety assessment 
process is the determination of the Failure Effects 
Classification for TASAR. The Failure Effects 
Classification then determines the development and 
validation requirements and processes to be followed 
in integrating TASAR as a flight deck application for 
certification and operational approval. 

Using this safety assessment process, applicants 
and certification and operational authorities (i.e., 
FA A aircraft certification and flight standards 
organizations) follow the process of assessing the 


new application and attendant procedures for 
potential failure modes and their impact on safety. 

Key Factors that Influence Failure Effect 
Classification of TASAR 

The following list represents key factors that 
influence the determination of the Failure Effect 
Classification for TASAR: 

1) TASAR is a supplemental system and thus is not 
relied on by critical functions supporting flight 
deck operations 

2) TASAR is optional, i.e., not a required system for 
flight operations. In the event of failures of the 
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TASAR system, TASAR can be ignored or 
disabled without adversely affecting operations 

3) TASAR has no MEL requirement 

4) TASAR can be manually inhibited at any time, 
for any reason: 

a) Detected failure of the TASAR application 

b) Detected failure of the host EFB 

c) Spurious or inconsistent performance of 
recommended change requests 

d) Distracting effects of TASAR to the pilot 

5) Presence or loss of TASAR does not change 
responsibilities of the pilot for flight operations 

6) TASAR is an “advisory-only” system (i.e., does 
not provide guidance information): 

a) Pilot is not reliant on TASAR outputs to any 
extent to perform flight operations 

b) Pilot can choose to utilize or ignore change 
requests candidates recommended by 
TASAR as part of change requests to ATC 


7) Change request procedures are unchanged: 

a) Pilot must direct all change requests to ATC 
using conventional means 

b) ATC is responsible for reviewing request for 
acceptability, including separation from 
traffic 

c) ATC either: 1) approves request and issues 
clearance, 2) provides an amended clearance, 
3) defers request to next controller, or 4) 
denies request 

8) Undetected, misleading information associated 
with TASAR outputs, i.e., with one or more 
candidate change request recommendations, will 
have “No Effect” on the pilot, aircraft, and/or 
ATC. Whether due to failure of one of the 
TASAR sub-systems and associated automation 
processing, or the result of inaccurate data 
obtained from ground-based or flight deck 
systems, spurious change requests are mitigated 
by flight crew inspection of the recommended 
trajectory change and by mitigations associated 
with the existing change request process. 
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Figure 2 Acceptable Risk versus Potential Effects (as defined for Civil Aviation) (from [6]) 


Failure Effects Classification 

Figure 2 (assembled from requirements specified 
in [6]) summarizes the mapping of the “Effects” due 
to failures and the allowable “Probability of 


Occurrence” that serve as the basis in determining the 
Failure Effects Classification of the planned 
application (i.e., TASAR). The applicant for the new 
capability and FAA certification and operational 
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approval personnel use Figure 2 to jointly determine 
the Failure Effects Classification of the system under 
consideration. Based on the key factors identified in 
the previous section, our safety analysis concludes 
that TASAR can be safely developed and 
implemented with a “No Effect” designation. 
Potentially TASAR could rise to “Minor Effect” in 
the event of inconsistent candidate change request 
recommendation(s), which could result in workload 
issues for the pilot and/or ATC. 

Workload issues are not anticipated to be an 
issue for the pilot’s use of TASAR, as the pilot can 
simply ignore TASAR for any reason. Through 
proper training in the puipose of TASAR, pilots will 
not likely allow themselves to be distracted or be 
adversely influenced in using TASAR while 
conducting flight operations. From an ATC 
perspective, controllers will continue to conduct the 
change request process as in today’s operation and 
are not expected to experience a workload issue due 
to TASAR. The only concern may be if a large 
percentage of users equip with TASAR, potentially 
causing the total number of requests to increase. 
However, the rate of adoption of new technology is 
typically gradual, which would mitigate this effect. 
In addition, proper design of TASAR is expected to 
result in informed, pertinent change requests that 
have an increased probability of ATC approval and 
thus are not expected to adversely impact the change 
request process or controller workload. 

Final determination of the Failure Effects Class- 
ification for TASAR requires a dialog between the 
applicant and FAA certification and operational 
approval authorities using the results of the safety 
analysis, resulting in a final designation by FAA. 
Initial feedback from these FAA authorities is 
presented at the end of the paper. 

Internal Mitigation Means 

The TASAR application itself provides 
additional inherent capabilities that further reduce the 
possibility of unintended adverse effects and are 
expected to enhance the usability of the application. 
The following TASAR capabilities further serve to 
strengthen and support the “No Effects” Failure 
Effects Classification for TASAR: 

1) In order to prevent lengthy, complex change 
requests from the pilot to ATC, TASAR utilizes 
standard navigation databases and places limits 


on excessive waypoints included in the 
recommended change requests it provides. 

2) TASAR displays flight path change opportunities 
using standard flight planning textual depictions 
to facilitate voice communications. 

3) TASAR may include capabilities to assess sector 
complexity and own-ship’s proximity to the 
sector boundary in order to only recommend 
change requests that have a high likelihood of 
being approved by ATC. 

Procedural Mitigations Available to the Pilot 

The following represent additional mitigations 
available to the pilot via procedural means: 

1) A characteristic of TASAR is that there is no 
“recovery” time required for the flight crew 
associated with its use. In other words, in using 
TASAR, the pilot remains on an ATC-cleared 
trajectory at all times. In the event of a TASAR 
system fault, the pilot need only remain on the 
current clearance while disregarding the TASAR 
display. A simple reset of TASAR, or by simply 
choosing to ignore TASAR inputs (e.g., by not 
looking at the TASAR display) allows the pilot to 
continue to focus on aviate-navigate- 
communicate priorities in conducting flight 
operations (whether during normal operations or 
in the event of abnormal or emergency 
situations). 

2) The pilot has responsibility to evaluate TASAR- 
provided Trajectory change request candidates 
for operational acceptability before making a 
change request to ATC, providing cross-check 
opportunities to detect spurious or false 
Trajectory change request candidates being 
offered by TASAR. 

3) Aircraft systems, e.g., FMS, weather radar, 
provide higher integrity information allowing 
quick check on acceptability and performance 
impacts of TASAR recommended change 
requests. 

Phase of Flight Considerations 

TASAR is intended for use primarily during en- 
route operations. Change request candidates are 
offered by TASAR during the latter portion of climb, 
while en-route, and to a lesser extent, into the early 
portion of descent operations. TASAR is thus used 
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primarily during non-critical phases of flight, i.e., 
above 10,000 ft. 

Information Source Quality 

Information source quality and integrity must be 
commensurate to support the Failure Effects 
Classification. Due to the “No Effect / Minor Effect” 
Failure Effects Classification anticipated for TASAR, 
TASAR input information quality and integrity 
requirements are driven more by operational use 
issues than by safety considerations. Low quality or 
misleading information can result in poor 
recommendations to the pilot for candidate change 
requests. The net effect, however, is simply that 
TASAR will not be as effective in achieving 
envisioned operational benefits (e.g., time or fuel 
saved). 

Undetected Failure - Worst Case Effect 

In the event of an undetected failure of the 
TASAR automation, inefficient routing is the only 
adverse outcome. Existing mitigation of any safety 


hazards is provided by ATC, as already is done for 
change requests today without TASAR. 

The Safety Analysis using Method 2 described 
in the next section takes a closer look at specific 
failure modes of TASAR, complementing the results 
from this section. 

Method 2 Safety Analysis - Operational Safety 
Assessment Process 

This section provides the safety analysis of 
TASAR using Method 2 [8] by applying the “bow- 
tie” model illustrated in Figure 3. The system of 
interest, in this case the TASAR application, is 
represented in the left-hand side of the bow-tie. The 
external environment in which the application 
operates, including environmental conditions (e.g., 
airspace influences, weather, traffic) and the external 
systems that are part of the overall operational 
concept (e.g., aircraft systems and ATC systems) are 
represented by the right-hand side of the bow-tie. 


TASAR 



AE 

Abnormal Event 

ASOR 

Allocation of Safety 
Objectives and 
Requirements 

BC 

Basic Cause 

OE 

Operational Effect 

OH 

Operational Hazard 

OHA 

Operational Hazard 
Assessment 
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Operational 
Services & 
Environment 
Definition 

SC 

Severity Class 

SO 

Safety Objective 

SPR 

Safety & 

Performance 

Requirements 

ST 

Safety Target 


Figure 3 Operational Safety Assessment Process - Method 2 


The OSA process consists of the following 
major sub-processes: 1) the Operational Hazard 
Assessment (OHA), and 2) Allocation of Safety 
Objectives and Requirements (ASOR). 

In performing the OHA, the first step is to use 
operational experts from all stakeholder communities 
to identify potential Operational Hazards that may 


result from the application (e.g., TASAR). For each 
identified Operational Hazard, the next step is to 
determine the worst “credible” outcome, also referred 
to as the Operational Effect (OE). Examples are 
collision, loss of separation, and workload. Figure 4 
provides the mapping of Operational Hazards to the 
associated Operational Effects due to each hazard 
class. 
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Hazard Class 1 (most severe) 2 3 

Effect on Operations Normally with hull Large reduction in safety margins Significant reduction in 

loss. Total loss of flight or aircraft functional capabilities, safety margins or aircraft 

control, mid-air functional capabilities. 

collision, flight into 

terrain or high speed 

surface movement 

collision. 

Effect on Occupants Multiple fatalities. Serious or fatal injury to a small Physical distress, possibly 

number of passengers or cabin including injuries, 
crew. 


Effect on Air crew Fatalities or 

incapacitation. 


Effect on Air Traffic Total loss of 
Service separation. 


Physical distress or excessive Physical discomfort, possibly 
workload impairs ability to including injuries or 

perform tasks. significant increase in 

workload. 

Large reduction in separation or a Significant reduction in 
total loss of air traffic control for separation or significant 
a significant period of time. reduction in air traffic 

control capability. 


Example of ASAS 

operational 

consequences 


Mid-air collision • 
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• 
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Controlled flight 

separation or safety 


in separation or 

into terrain 

margins 


safety margins 
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• 
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flight control 

in wake vortex encounter 


resulting in wake 

High speed 

at low altitude. 
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movement 
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• 
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Leaving a 
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• 

Leaving a prepared 
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surface at low speed 
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• 

Significant reduction 

speed. 

functional capabilities 


in aircraft functional 

• 

Total loss of air traffic 


capabilities 


control for a significant 

• 

Significant reduction 


period of time 


in air traffic control 
capability 


4 5 (least severe) 

Slight reduction in safety No effect on operational 
margins or aircraft capabilities or safety 

functional capabilities. 


Physical discomfort. Inconvenience. 

TASAR OSA F ocus Areas 

blight increase in workload^ ^Jo effect on flight crew. 


Slight reduction in 
separation or in ATC 
capability. Significant 
increase in air traffic 
ontroller workload. ^ 

^ngnt reauction in 
separation or safety 
margins 

Significant increase in 
air traffic controller 
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Slight increase in air traffic 
control ler workload . 
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traffic controller 
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No effect on flight 
crew 


Figure 4 ED78A/D0264 Based Hazard Classification Matrix 


For each Operational Hazard and associated 
Operational Effect, the Severity Class is determined. 
Severity Classes include catastrophic, severe major, 
major, minor, and no effect. For each Operational 
Effect and associated Severity Class, a “Probability 
of Occurrence” not to be exceeded to assure safety of 
operations is established, ranging from 10 9 , 10' 7 , 
10 5 , I O ', etc. for occurrence of the Operational 
Effect. The Operational Effects and Severity Classes 
are noted in Figure 3 on the right side of the bow-tie. 

Potential Operational Hazards and Mitigations 

Figure 5 provides a summary of the Operational 
Hazards (denoted as OH-x, x=l to 7) that were 
identified for TASAR. Also included is a brief 
description of the Operational Hazard and the major 
mitigation(s) that were identified. Based on the 
Operational Hazards identified and evaluated in 
Figure 5, it is evident that the region of interest for 
TASAR falls under the highlighted areas in Figure 4 
(i.e., Hazard Class 4 and 5). The highlighted regions 
represent “No Effect” and “Minor” Failure Effect 
Classifications. This determination is further 
strengthened by the availability of strong External 


Mitigation Means (right side of Figure 3) that are 
already in place as part of today’s change request 
procedure. Thus, only an “abbreviated” OSA was 
conducted, focusing on identifying Operational 
Hazards that could potentially occur when using 
TASAR. 

Identification of TASAR Operational Hazards 
serves to complement the analysis results of the 
safety analysis results using Method 1 . More specific 
details on both these safety analysis methods as 
applied to TASAR, and identification of Abnormal 
Events and Basic Causes that may lead to the 
occurrence of Operational Hazards for TASAR are 
found in [9]. Consistent with the safety assessment 
used in Method 1, the Operational Safety Assessment 
used here (i.e., Method 2) the most likely Failure 
Effect Classification for TASAR would be “No 
Effect” or at most “Minor”. With either of these 
classifications, TASAR is amenable for integration as 
an EFB application. The standards adherence 
requirements of EFB applications are discussed in the 
next section. 
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Operational Hazard 

Description 

Mitigation 

OH - 1: TASAR could provide one or 
more change request candidates that 
are not conflict free 

This Operational Hazard is the result of poor 
information quality and/or mixed ADS-B Out equipage 
environment, where not all traffic is known 

ATC provides separation assurance 
independent of TASAR 

OH - 2: Pilot could misinterpret TASAR 
candidate change request and could 
unknowingly request a trajectory 
clearance that is not conflict free or 
could lead toward hazardous airspace 

TASAR could "inadvertently" mislead or confuse the 
pilot who could then misrepresent the TASAR change 
request to ATC 

ATC provides separation assurance 
independent of TASAR 

Aircraft safety systems (e.g.. Traffic Alert and 
Collision Avoidance System, weather radar, 
Terrain Awareness and Warning System) 
provide hazard detection and alerting 

OH -3: Pilot could follow the wrong 
trajectory clearance following receipt of 
amended clearance from ATC 

Pilot could request a change recommended by the 
TASAR system, and although ATC amends the request, 
TASAR-induced confusion could lead the pilot to follow 
the request instead of the clearance 

ATC monitors execution and intercedes (same 
as today) 

Pilot training 

Pilot crosschecks clearance with FMS 

OH -4: ATC, somehow being aware of 
TASAR capability for the aircraft / pilot 
requesting a change request to the 
flight plan, could be less vigilant to 
provide separation assurance 

The concern is whether ATC could become complacent 
over time, when receiving TASAR requests 
(note that TASAR equipage is not specified on filed 
flight plans or included in pilot-request verbiage) 

Existing ATC procedure to check all requests for 
separation 

Note: This is not a credible Operational Hazard 
because separation assurance is ATC's primary 
responsibility 

OH -5: TASAR could provide numerous 
spurious and/or inconsistent series of 
change request candidates leading to 
multiple requests 

If change request recommendations are not reinforced 
from one request to the next, multiple counteracting 
requests could be issued 

These requests could become a nuisance issue and 
potentially could lead to a workload issue for ATC 

ATC denies user requests if workload is too 
high 

OH -6: TASAR could recommends a 
trajectory candidate with 
miscomputation of fuel burn 

Pilot reliance on TASAR fuel burn estimates (presented 
to help pilots choose between multiple request 
options) could lead to greater fuel burn than expected 

Pilot crosscheck of FMS prediction of fuel burn 

OH -7: Unexpected weather could 
develop on TASAR recommended route 
after ATC approval 

Unexpected weather could require additional change 
requests and therefore more fuel to be used 

Normal procedures for responding to 
unexpected weather 


Figure 5 TASAR Operational Hazards and Mitigations 


EFB Standards Adherence 

The second half of this paper focuses on 1) EFB 
standards adherence requirements for the certification 
and operational approval of TASAR, 2) identification 
of artifacts needed in support of the certification basis 
and means of compliance of approval of TASAR, and 
3) review of the elements of a Project Specific 
Certification Plan (PSCP) that may need to be 
followed as part of the eventual certification and 
operational approval of TASAR as a fielded product. 
This information was developed in support of 
NASA’s TASAR research program as preliminary 
steps toward a potential future certification project of 
TASAR, but in itself does not constitute an actual 
certification program. 


Current EFB Industry Trends 

Before describing the EFB standards adherence 
requirements for TASAR, this section provides an 
overview of current trends in the aviation industry’s 
use of EFB to provide additional functionality and 
applications to the flight deck. 

1) EFBs and their software applications provide (or 

are anticipated to provide) a retrofit path for new, 
increasingly more capable flight deck 

capabilities. The increased ability of commercial 
off-the-shelf (COTS) PEDs is providing impetus 
to add new capabilities economically. 

2) Airlines are beginning to see cost-benefits of 

EFBs, often with different business cases to 
equip. They see reduced pilot workload, 
simplified flight operations, and greater 

situational awareness as key benefits. 
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As increasingly more capable EFB applications 
are identified and being considered for 
integration in the flight deck, these EFB 
applications are transitioning from standalone, 
low-certification level (e.g.. Minor) hosted app- 
lications on a PED EFB, to applications that 
interface with higher-criticality avionics systems 
(read-only, transmit-only, or both), while at the 
same time also being connected to external 
networks. Consequently, FAA and industry must 
require sufficient protections to prevent 
interference by the PED EFB to avionics systems 
(e.g., Electro-Magnetic Interference (EMI) 
protection), provide cyber security, and require 
an Aircraft Interface Device (AID) that serves as 
a trusted interface between more critical avionics 
systems and the lower criticality COTS PED 
EFB. From the TASAR perspective, by requiring 
a read-only interface, and being an advisory-only 
system that can be disabled at any time, this 
allows a relatively low threshold for approval. 

It is reiterated that it is the intended function of 
an EFB application that is paramount in 
determining the extent to which EFBs can be 
utilized to provide functions in the flight deck. 
Based on feedback from FAA approvers, 
TASAR, as currently defined, falls well within 
the acceptable use of EFBs to provide operational 
benefits to the end user. 

3) EFBs are becoming sought-after, low-cost flight 
deck tools for improving situational awareness 
and leading to improved pilot decision making. 
They allow the flight crew to connect in real time 
to the rest of the world (e.g. TASAR via data link 
connectivity to internet information sources for 
weather, traffic, airspace status data, etc.). 

4) While EFB hardware requirements and 
specifications remain important, hardware is 
expected to become commoditized, with future 
focus shifting to development of more robust 
software applications (refer to FAA AC 120-76B 
[10] for definitions and approval requirements 
associated with EFB hardware and software). 

6) The latest technological development for Class 2 
EFBs is their ability to interface with aircraft 
systems and to provide an access point to 
wireless communications pipelines (similar to 
those planned for TASAR data connectivity). 


7) Once ADS-B IN becomes available for display in 
aircraft, benefits of EFB may become significant. 
However, depending on the intended function, 
this likely raises the criticality for such EFB 
software applications, which may go beyond 
“Minor” of Type A and Type B applications. 

TASAR already utilizes ADS-B IN traffic 
information as part of its computation of conflict 
free trajectory candidates. However, it does not 
display own-ship or other traffic to the pilot and 
thus remains closely aligned with Type B 
applications, i.e., it consists of processing 
algorithms similar to those associated with Type 
B applications. TASAR is expected to be less 
critical than Type B applications associated with 
Weight and Balance, and Performance calcula- 
tions. 

8) There is a likelihood that EFB systems with 
hosted Type A and Type B applications and with 
approved software (those designed using DO- 
178B) will be integrated in some installations. 
This likely requires a dual-processor EFB 
architecture, allowing partitioning of higher and 
lower criticality software applications. For 
example “approved” DO-178B certified software 
applications to be allocated to one EFB processor 
running DO- 178B -certified Linux Operating 
System (OS), and Type A and Type B “hosted” 
applications (developed without DO-178B) 
running on a non-certified Windows OS. 
Alternate architectures and approaches can be 
considered if equivalent in robustness. 

9) TASAR, as a hosted application, may be 
integrated with other software applications (some 
hosted and perhaps some approved) and may be 
installed in a variety of EFB platforms including 
some with certified OS. The manner of 
integration and hosting of TASAR may affect the 
software certification requirements of its design. 

Key FAA Regulatory Documents 

The following represent some of the cornerstone 
regulatory documents from FAA that provide 
guidance information and requirements that must be 
met in order to gain certification and operational 
approval for EFB-based flight deck applications. 
These documents were reviewed and assessed in 
detail in order to identify expected EFB standards 
adherence requirements for TASAR. These 
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documents point to numerous secondary documents 
not listed here that contain additional approval 
requirements that an applicant must address as part of 
a certification project with FAA: 

1) Title 14 of the Code of Federal Regulations (14 
CFR) parts 21, 23, 25, 27, 29, 43, 91F, 91K, 121, 
125, and 135 [11] 

2) Flight Standards Information System (FS1MS) - 
8900.1 Change 47, Vol. 4, Chapter 15 - EFB 
Operational Authorization Process [12] 

This document provides the FAA approval 
perspective, providing the Principal Operations 
Inspector (POI) checklists followed for EFB and 
associated applications approval, including 
approval considerations for TASAR. 

3) AC 120-76B, Guidelines for the Certification, 
Airworthiness, and Operational Approval of 
Electronic Flight Bag Computing Devices [10] 

This document is intended for operators 
conducting flight operations under Title 14 of the 
Code of Federal Regulations (14 CFR) part 121, 
125, 135, or 91 subpart F (part 9 IF) and part 
9 IK. It is a key guidance document for EFB use 
with applicability to TASAR. 

4) AC 20-173, Installation of Electronic Flight Bag 
Components [13] 

5) FAA Order 8 1 10.4C, Type Certification [ 14] 

6) RTCA/DO-160G, “Environmental Conditions 
and Test Procedures for Airborne Equipment”, 
[15] 

Pertains to EMI and High Intensity Radio 
Frequency (HIRF) requirements for read-only 
and transmit data interfaces to avionics, 
respectively. TASAR requires read-only access 
to avionics, and thus will need to meet EMI 
requirements (or delegate this requirement to an 
AID). In addition, TASAR wireless connectivity 
likely requires additional isolation testing (i.e., 
TASAR as a Transmit-PED) to ensure non- 
interference to avionics. 

7) AC 20-115, RTCA DO-178B, Software 
Considerations in Airborne Systems and 
Equipment Certification [16] 


TASAR as a Class 2 EFB 

EFB hardware Classes (1, 2, or 3) are described 
in [10]. TASAR is envisioned to be implemented as 
a Class 2 EFB application. It requires a read-only 
interface to avionics systems, connection to aircraft 
power, and data link connectivity for access to 
ground information sources (refer to Figure 1). 
TASAR is anticipated to be implemented as a 
“mounted PED”, i.e., a Class 2 EFB. The mounted 
PED requires interface through an AID. The 
combination PED EFB and AID represent the Class 2 
EFB planned for TASAR. The TASAR EFB must be 
capable of being easily removed from or attached to 
its cockpit mount by flight crew personnel. A 
cockpit mount is planned (versus a yoke mount), for 
reduced approval requirements. The TASAR EFB 
with associated AID must be installed in accordance 
with AC 20-173 [13]. The portable Class 2 EFB 
components of TASAR are not considered to be part 
of aircraft type design; i.e., not in the aircraft Type 
Certificate (TC) or Supplemental Type Certificate 
(STC). 

Class 2 EFB Approval Requirements 

This section examines the approval requirements 
for a Class 2 EFB hosting a TASAR application. 

High-Level Steps for Installation and 

Operational Approval of a Class 2 EFB 

The following represents the high-level steps 
needed to be followed for the installation and 
operational approval of a Class 2 EFB for TASAR: 

1) Applicant must obtain approval via TC or STC 
for initial alterations related to: 

a) mounting fixture installation 

b) installation of power and/or data 

connectivity. 

2) Manufacturer, provider, or installer must assure 
via testing that the Class 2 EFB provides 
interference-free operation. If a data transmitter 
is used to transmit data to the Class 2 EFB, it 
must be tested to RTCA DO-160G, section 21, 
paragraph M [15], ensuring conduction/ radiation 
of emissions do not result in interference. 

3) Applicant must obtain TC, STC approval or 
Designated Engineering Representative (DER) 
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approval for installation of antennas that provide 
data to the EFB, e.g., navigation, weather data. 

TASAR falls into this category, as it seeks to 
access information from network-enabled 
information services. However, since TASAR is of 
“No Effect” or “Minor”, the data integrity required is 
expected to be relatively minor. TC, STC, or DER 
approval requirements of installed antennas are to be 
determined with further analysis. 

FAA Involvement in EFB Approval Process 

FAA offices involved in the EFB approval 
process are: 1) Certification (AIR), 2) Aircraft 
Evaluation Group (AEG) - Flight Standards (AFS), 
and 3) the Principal Operations Inspector (POI). The 
role of AIR is to issue approval of type design of 
installation for inclusion in the TC/STC. AEG may 
evaluate new EFBs and prepare an Operational 
Suitability Report (OSR). The POI conducts reviews 
and issues authorization by Operational Specification 
(OpSpec) or by Management Specification (MSpec) 
and Letter of Authorization (LOA), A061. 

Operator Requirements 

The following are requirements to be met by the 
Operator for the intended function of the EFB, e.g., 
TASAR: 

1) Develops the program for usage 

2) Completes an operational evaluation of the new 
capability 

3) Ensures that the system performs its intended 
function 

4) Documents non-interference per AC 91.21-1 [17] 

5) Ensures non-interference and isolation from air- 
craft systems during transmission and reception 

6) Determines usage of hardware architectural 
features, persons, procedures, and equipment to 
eliminate, reduce, or control risks associated with 
hardware failure 

Note: Installed elements of Class 2 EFBs must 
be entered into aircraft records when added or 
removed. 


EFB Software Considerations by “Type” 

AC 120-76B [10] provides detailed definitions 
and description of EFB software related factors (e.g.. 
Type A, B, C; hosted versus approved software). 
Type A applications (listed in Appendix 1 in [10]) are 
paper replacement applications intended for use 
during flight planning on the ground and during non- 
critical phases of flight. Type B applications (listed 
in Appendix 2 in [10]) are intended for use during 
critical phases of flight or have algorithms that must 
be tested for accuracy and reliability by the applicant. 

Sample Type B applications are 1) display of 
aeronautical charts viewable electronically and allow 
chart manipulation, 2) Electronic Checklists available 
in all phases of flight, 3) Weight and Balance 
calculations/algorithms, 4) performance calculations. 
These must be tested and proven by the applicant. 

While TASAR is currently neither a Type A or 
Type B application as defined in [10], it has some 
key characteristics related to Type B software 
applications: 1) intended for use during flight 

planning (in case of TASAR, primarily during en- 
route phase of flight, but potentially during the later 
stages of climb, and early stages of decent), 2) 
includes variables in the information presented based 
on data-oriented software algorithms (in case of 
TASAR, using a variety of information sources for 
subsequent processing to determine trajectory change 
candidates), and 3) Failure Effects Classification of 
no more severe than “Minor”. 

While TASAR is similar to a Type B 
application, it is anticipated that it has a lesser 
threshold for approval over traditional Type B 
applications. With TASAR being an optional, 
supplemental, and advisory support tool, that the 
flight crew can use at their discretion (i.e., can choose 
to ignore or disable at any time for any reason), it can 
be readily viewed as a Type B application. 
Appropriate pilot training will ensure that the flight 
crew will not be distracted by TASAR during flight 
operation while conducting normal and off-nominal 
operations. As is the case for Type A and B 
applications, TASAR is not expected to require DO- 
178B software development and certification as part 
of the approval process. 
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Approver and Stakeholder Responsibilities 

The following responsibilities are identified for 
the various approvers and stakeholders in the 
approval process of the TASAR EFB Application: 

FAA Principal Operations Inspector (POI): 

1) Verifies that: 

a) application criteria and operator requirements 
are met 

b) data updates follow maintenance manual and 
inspection program procedures 

c) applicable job aids, including human factors 
evaluation are completed 

d) training, checking, and currency programs 
are approved 

e) operational evaluation report from operator is 
appropriately reviewed 

f) OpSpec or MSpec A061 is issued upon 
completion of authorization process 

2) Ensures that the level of information integrity is 
commensurate with the Failure Effects 
Classification of TASAR (i.e., “No Effect” or no 
more than “Minor”) as noted earlier. 

Note: As part of the approval process the POI 
follows detailed checklists found in FS1MS 
8900.1 Change 47, Vol. 4, Chapter 15 [12]. 
Checklist questions are specific to initial 
installations and training for a given aircraft. 
Four POI checklists are provided in Figures 4-79 
to 4-82 in [12], 

Flight Standards Service (AFS) 

AFS provides initial operational authorization 
granted for hosted application(s) (e.g., performance, 
weight and balance applications) based on AIR 
recommendations and AEG determination of flight 
crew training, checking and currency requirements. 

Operator Requirements 

The Operator must address the following 
requirements as part of the approval process: 

1) Determines usage, architectural features, people, 
procedures, and equipment to eliminate, reduce, 
or control risks associated with an identified 
failure in a system 

2) Performs 6 -month operational validation per 
authority granted in OpSpec or MSpec A06 1 


3) Uses both EFB device / system and conventional 
paper copies during evaluation (not applicable for 
TASAR) 

4) Submits final evaluation report to the POI, as 
appropriate after evaluation 

5) Ensures operating system and hosted application 
software meet criteria for appropriate intended 
functions and do not provide false or hazardously 
misleading information 

6) Ensures software revision loading won’t corrupt 
data integrity of original software. 

Depending on how the TASAR application will be 
integrated in a PED / EFB will dictate the level of 
partitioning required: 

1) If TASAR is standalone, with its own dedicated 
processor (own OS and application software) and 
dedicated display, this will not require any 
partitioning or special protections. 

2) If TASAR has its own dedicated processor, but 
shares a common display with other “Approved 
Software” applications / software (per above 
definition), recommended Display Standards, 
e.g., AC 25-11, Electronic Flight Deck Displays 
(for Part 25 aircraft) [18], and AC 23.1311-1, 
Installation of Electronic Display in Part 23 
Airplanes [19] must be followed. 

3) If TASAR is hosted with other approved 
software applications in a shared processor, 
approved partitioning techniques must be 
followed. These techniques are required to 
guarantee throughput and resources (e.g., 
memory, hard drive, avionics data) of approved 
software applications. 

PS CP Overview 

In addition to the TASAR EFB hardware and 
software requirements discussed in the previous 
section, a review and assessment was made of the 
requirements and engagement activities with FAA 
Certification and Operational Approval personnel. 
Specifically, the makeup of a PSCP was reviewed. 
To the extent possible, artifacts were identified and 
TASAR-specific details were identified without fully 
going through the actual certification process. 
Subsequent to completion of this assessment of 
TASAR EFB requirements, development of a PSCP, 
and development or description of some of the PSCP 
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artifacts for TASAR, a dry-run was held with in- 
house Rockwell Collins DERs representing software 
and hardware certification disciplines. 

The PSCP represents the composite of both the 
applicant’s and FAA’s project plan information as 
part of the certification and operational approval 
process. The key element of the PSCP is the 
Compliance Check List, which indicates that the 
applicant understands all appropriate regulatory 
requirements to be satisfied for achieving 
certification and operational approval. The 
Compliance Check List provides a summary of the 
regulatory requirements via reference and points to 
the type of associated data submittals (i.e., artifacts) 
that need to be provided to approving authorities. 

The PSCP is important as part of the 
engagement process with FAA for product 
certification and approval and ensures that the 
individual elements of the plan take place in proper 
order and at designated timeframes. This allows for 
planning of personnel and resources by both the 
applicant and FAA and provides a roadmap for 
coordination, information exchanges, and milestone 
completion dates. Without a well-coordinated PSCP 
and associated schedule information, the certification 
project stands little chance for timely completion. 

The compilation of TASAR-specific EFB 
requirements, the make-up of a notional PSCP, and 
associated artifacts that were developed for the 
TASAR application were reviewed with two DERs, 
representing both software and hardware certification 
disciplines and expertise. Without exception, DER 
reviewers were in concurrence with the information 
presented to them for TASAR certification 
requirements, and offered additional advice, 
clarification, and perspective on a number of points. 

The following certification and operational 
approval artifacts and requirements were reviewed: 

1) Overview of the certification and operational 

approval plan, i.e., the PSCP 

a) Brief overview of the 5 phases of the PSCP, 
i.e., conceptual design, requirements, 
compliance planning, implementation, and 
post certification phases 

b) Brief review of the typical content of a PSCP 

c) Review of the PSCP as applied to TASAR 


2) Review of cornerstone EFB documents (FARs, 
regulatory, and guidance) 

3) Certification approval considerations for the 
TASAR EFB application, i.e., assumptions, 
industry trends of EFB applications, key points 
and observations related to certification approval 
of the TASAR EFB, and software and hardware- 
specific approval considerations and compliance. 

5 Phases of Certification 

1) Conceptual design phase - early activities that 
define the envisioned product and intended 
function being considered by the applicant (e.g., 
concept of operations, use cases and scenarios, 
human-machine interface, high-level hardware 
and software sub-system design as preliminary 
architectures). Identifies new designs, 
technologies, materials, processes, etc. Includes 
early formulation of a PSCP. Provides initial 
safety assessments. 

2) Requirements phase - refines and clarifies the 
product definition and begins development of the 
PSCP. Applicant develops descriptive design 
and production data, identifies critical issues. 
Safety assessments are refined. A proposed 
certification project schedule is provided. 

3) Compliance planning phase - PSCP is completed 
and agreed to, i.e., signed, in this phase, which 
establishes the roles of all responsible parties in 
the certification process. Initial Failure Mode 
Effects Analysis and safety assessments are 
provided, critical issues are refined, and 
production processes are provided. The type 
certification basis is established and the 
compliance check list is provided. 

4) Implementation phase - the applicant and FAA 
work to the PSCP and make necessary 
adjustments as needed to ensure that all agreed to 
certification requirements are met. Compliance 
to the FARs, regulations and guidance documents 
is demonstrated and verified. Analyses, test 
plans and tests, conformity inspections, flight 
tests, final safety analyses are completed. If all 
certification criteria are demonstrated, and 
verified, the product certification is approved. 
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5) Post-certification phase - serves as close-out 
activities that identify steps to be performed to 
ensure continued airworthiness of the product. 

Elements of the PSCP 

The following is a representative outline of a 
PSCP amenable for use for TASAR approval: 

1) Purpose or Introduction 

Identifies the intent of the certification plan. 

2) Description 

Brief description of the system, product and 
associated application. 

3) Federal Aviation Regulations 

Lists applicable regulations by sections, 
subsections, including the amendment level if it 
differs from the established certification basis. Plans 
for exemptions, equivalent levels of safety, or special 
conditions should be included, if known. 

4) Compliance 

States how compliance will be shown; provides 
analysis results of failures and safety performance. 
Indicates tests conducted, e.g., qualification, ground, 
and flight tests. Demonstrates software compliance; 
design inspection results. Use of unique 
methodologies should be noted in the certification 
plans. Compliance data should be part of the 

certification plan. 

5) Conformity 

Identifies parts of the installation required for 
conformity. Ensures parts are built to specifications. 

6) Data 

Lists data to be submitted to show compliance. 
It is acceptable for report and drawing numbers to be 
deferred to later. 

7) Airplane Flight Manual (AFM) 

Indicate revisions to the AFM if needed. 

8) Type Certificate Data Sheet 

Indicates if data sheet needs revision and how. 

9) Proposed DER(s) 

Project certification official (ACO) determines 
appropriateness of assigning designees to represent 


the FAA, e.g., DER. The ACO may not delegate the 
authority to approve certain aspects of a project. 

10) Master Minimum Equipment List (MMEL) 

Indicates if the MMEL is affected. 

11) System Criticality 

For applicable systems, the results of the 
preliminary function hazard analysis need to be made 
known, e.g., system criticality, software criticality, 
functional failure conditions summary. 

12) Schedule 

Provide a schedule which shows the following: 
Significant milestones, when preliminary hazard 
analysis will be submitted, detail of data submittals 
(drawings, compliance reports, and test schedule), 
conformity and airworthiness inspections, 
compliance inspection schedule, and final approval 
date anticipated. 

FAA Feedback Results 

The NASA TASAR team met with FAA 
certification (AIR) and operational approval (AFS) 
representatives to present the analysis results 
presented in this paper and to gain FAA feedback. 
The feedback confirmed our analyses and that our 
assessments were on track. The following is a 
summary of FAA feedback on the results we 
provided: 

1) TASAR meets the definition of a Type-B 
application and does not need to be added 
explicitly to the list of Type B applications in 
Appendix 2 of [10]. Type-B applications running 
on non-certified hardware (e.g.. Class 2 EFB) do 
not require DO-178B compliance. 

2) TASAR is not considered an “ADS-B IN 
application” but rather a performance / planning 
application that leverages ADS-B IN data, if 
available. 

3) No need was identified to establish a TASAR 
standard. 

4) TASAR should be viewed as a “Minor Effect” 
application because of potential pilot workload 
associated with TASAR due to misleading/bad 
data. From a loss of function standpoint, TASAR 
is viewed as “No Effect.” 
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5) If an end user already has an existing EFB 
installation, then the operational approval process 
is for the user to go directly to the Principal 
Operations Inspector (POI). 

6) Existing policies already cover the proposed 
TASAR application. 

Summary 

This paper illustrated the result of safety analyses and 
review of the intended function of TASAR in 
establishing the “No Effect” or “Minor” Failure 
Effects Classification. EFB Standards Adherence 
Requirements were reviewed and resulted in 
determination that TASAR can be implemented as 
Type B software hosted on a Class 2 PED EFB. An 
Aircraft Interface Device is also required as part of 
the cockpit-mount PED EFB to allow interference- 
free, read-only access to on-board avionics systems, 
and to provide data link connectivity via installed 
antennas for accessible information sources, e.g., 
weather information, etc. This paper also delineated 
the roles and responsibilities of the operator, 
manufacturer, installer, avionics vendor, and FAA 
certification and operational approvers of newly 
developed EFB applications, such as TASAR. An 
overview of the steps that need to be followed as part 
of a PSCP for achieving approval for TASAR was 
also provided. Results of TASAR safety, 
certification and operational approval analyses and 
assessment were briefed to FAA approvers who 
generally concurred with our assessment and 
provided valuable feedback. Based on this feedback, 
an applicant should have no difficulty in getting 
approval to implement TASAR from their standpoint. 

Ongoing Research and Future Plans 

NASA research on TASAR is continuing and 
the TASAR EFB application that has been developed 
is being tested by airline pilots in high-fidelity 
simulation and in a flight test aircraft operating in 
ATC-controlled airspace using real-world data flows. 
The concept, development, analyses, and test results 
are being documented and will be made available as 
artifacts to support initial applicants in the FAA 
approval process. Test and evaluation results are 
planned to be documented in future reports. 
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